home *** CD-ROM | disk | FTP | other *** search
/ SPACE 1 / SPACE - Library 1 - Volume 1.iso / program / 113 / gfatip10 / gfatip10.doc next >
Text File  |  1987-10-10  |  4KB  |  91 lines
  1.  
  2.  
  3.                                                 October 10, 1987
  4.  
  5.  
  6.                            GFATIP10.DOC
  7.  
  8.                         by John B. Holder
  9.                      Senior Software Engineer
  10.                      Marathon Computer Press
  11.            Asst. Sysop on GEnie's MichTron Roundtable
  12.  
  13.  
  14.      This is the 10th in a planned series of GFA Tip files.  The 
  15. topic of this issue is utilizing the entire range of ASCII 
  16. characters as obtained with the INKEY$ function in GFA Basic.  In 
  17. this archive you will find the following files:
  18.  
  19.                    Inkey.Bas | the demo program
  20.                 GFATIP10.DOC | This text file
  21.  
  22.      Since the enclosed program file is fairly self explanatory, 
  23. I'll keep this file pretty short.  I'll give you a short 
  24. explanation of what Inkey$ does for you and refer you to the 
  25. manual for the complete description.  Then I'll tell you what we 
  26. have done & how it relates to software utilized in this country 
  27. and that in Europe.
  28.  
  29.                    Technical aspects of INKEY$
  30.  
  31.      The INKEY$ function within GFA Basic returns a value for a 
  32. pressed keyboard key (or combination of keys).  This value can be 
  33. either 1 or 2 bytes long.  If the key pressed falls within 0 and 
  34. 128 on the ASCII scale, the value will reflect the key pressed and 
  35. will be only 1 byte long.  However, if the key pressed value is 
  36. higher than 128 ASCII, the value becomes a 2 byte long string.  
  37. That is where we run into problems.  Without our little fix, we 
  38. would effectively lose many of the printable characters that are 
  39. obtainable with the ST.  The reason for this is that the current 
  40. versions of GFA Basic pad this two byte value with a preceding 
  41. null byte if the ASCII value is >128.  In a sense what it is 
  42. actually doing is giving you this => CHR$(0) + CHR$(Key Pressed 
  43. (minus) 128).  Why it utilizes this format, I can't answer.  
  44. Unlike the INP(2) function which returns all key values as 
  45. obtained from the keyboard, INKEY$ uses this abnormal value 
  46. padding scheme.
  47.  
  48.                       What's this all about?
  49.  
  50.      A lot of GFA Basic user's have been disgruntled about the 
  51. filtering of all of the special printable characters by the INKEY$ 
  52. function, (myself included).  Many applications call for full 
  53. keyboard access on the fly.  Since this is not possible with 
  54. INP(2), the only logical answer was to try to use INKEY$.  But 
  55. with the filtering that it was doing, it appeared impossible to 
  56. accomplish.  Since it took on that gloomy aura, and since I was 
  57. told that it was a hopeless cause, I decided to tackle the problem 
  58. for my own benefit and that of everyone that was interested.  By 
  59. utilizing GFA Basic's rich suite of commands I found the loophole 
  60. to make a FULL KEYBOARD ACCESS routine with INKEY$ a reality.  
  61. Since we have the CVI command in GFA Basic it was a snap to pull 
  62. off.  What CVI does is convert a two byte string into a 16 bit 
  63. integer.  Well, once I stumbled onto that and realized what INKEY$ 
  64. was doing, I just put two and two together and converted the 
  65. string to an integer and added 128 to it if the value of INKEY$ 
  66. was more than two bytes long.  EUREKA!  Some of you might now be 
  67. thinking, "Gee you could do that with Right$() and Val() too!".  
  68. This is true, but it is much more elegant with CVI and requires 
  69. fewer steps too!
  70.      The significance is that when used properly, the INKEY$ 
  71. function can now do everything that Form Input does currently 
  72. albeit in a more interactive mode.  Not only that, it will allow 
  73. our European friends to utilize your programs with the full access 
  74. to their character set.  Before, the INKEY$ function was screening 
  75. out those values.... Not Nice!
  76.      Due to time available, I did not have a chance to write a 
  77. program that would function in all three resolutions, so I stuck 
  78. to the MEDIUM resolution mode.  But not to despair, the program is 
  79. just a fancy way of getting across the significance of this INKEY$ 
  80. discovery.  I have outlined the procedure very clearly in the 
  81. source code for you.  Also as an added bonus I've thrown in the 
  82. way you find out what version of the Interpreter that you have.  
  83. It'll appear in the form of an alert box when you press the ESCAPE 
  84. key to exit the program.  Enjoy!
  85.  
  86.                               John B. Holder
  87.                               Asst. Sysop On MichTron RT @GEnie
  88.                               Address => GRIFJOHN
  89.  
  90.  
  91.